
REMARKS 



The claims have been revised in several aspects. Claims 48, 63, and 76 have been 
amended to correct the errors noted on page 2 of the Office Action. 

Claims 41, 51, 67, and 74 originally recited that the control unit was provided "with" 
the video and audio messages. Although the control unit does receive these messages, they 
can be temporarily stored in a holding site separate from the control unit. For example, as 
described in the specification at pages 26 and 27 and covered in Claim 57, the messages can 
be stored in a message queue where they are available to the control unit. To make it clear 
that the messages are not necessarily provided directly to the control unit, Claims 41, 51, 67, 
and 74 have been amended to recited that the video and audio messages have been provided 
"for use by the control unit". Claims 42, 43, 57, and 59 have been amended to conform to 
the revised version of Claim 41 . 

No claims have been added or canceled. Accordingly, Claims 41-82 remain 
pending. 

Claims 41-82 have been rejected under 35 USC 1 12 as failing to comply with the 
written description requirement on the grounds that "The claim(s) contain subject matter 
which was not described in the specification in such a way as to reasonably convey to one 
skilled in the relevant art that the inventor(s), at the time the application was filed, had 
possession of the claimed invention". This rejection is respectfully traversed. 

With respect to Claims 41 and 67, the Examiner alleges that the limitation that the 
data packets be demultiplexed and depacketized without interrupting the control unit is not 
supported by the specification. This limitation has two basic components: 
(a) a demultiplexing/depacketizing sublimitation and a non-interruption sublimitation. 

The sublimitation that the data packets be demultiplexed and depacketized is 
supported at various places in the specification. On page 2 in the first paragraph of the 
Summary section, the specification first states that "The stream demultiplexer demultiplexes 
and depacketizes the raw DVD data stream, subsequently stores the video and audio data in 
the storage buffer and informs the CPU thereabout". The specification goes on in the last 
paragraph on page 2 to say more particularly that "The stream demultiplexer extracts the 
timing information embedded in each data pack of a data stream and, accordingly, generates 
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a tag containing the decode time stamp, the presentation time stamp and the storage location 
of each data pack stored in the buffer". 

Further detail is presented in the Detailed Description in the paragraph bridging pages 
7 and 8 where the specification states that "SD 26 first demultiplexes the audio, video and 
control components of the received DVD data" and thereafter that "SD 26 depacketizes the 
demultiplexed data, namely, SD 26 removes header 208, DTS 210 and PTS 212 from each 
packet 206 before storing the payload 214 in buffer 48". Hence, the 
demultiplexing/depacketizing sublimitation is supported in the specification. 

The sublimitation that the demultiplexing/depacketizing be done "without" 
interrupting the control unit is likewise supported in the specification. In the Summary 
section on page 3, the specification states in the second paragraph that "in a steady state and 
under normal operating conditions, the CPU is interrupted only when the synchronization 
signal arrives [emphasis added] thereby significantly reducing the number of interrupts that 
the CPU must service". The specification similarly states in the Detailed Description in the 
paragraph bridging pages 1 1 and 12 that "in a steady state and under most operating 
conditions, CPU 54 is interrupted only when a tag is present at the occurrence of a 
subsequent Vsync signal [emphasis again added]; this is an advantage of the DVD/DVB 
decoder 20 which generates fewer interrupts than do other known systems". 

The "control unit" of Claims 41 and 67 is embodied by the CPU mentioned in the 
material quoted from the pages 3, 1 1, and 12. As provided on pages 3 and 9, the video 
output processor (40) generates the synchronization signal (Vsync). Since the 
synchronization signal causes the video and audio decoders to decode the video and audio 
data produced from the demultiplexed and depacketized incoming data stream, the 
demultiplexing and depacketizing of the data packets is performed without interrupting the 
control unit. 

The specification goes on in more detail in the paragraph bridging pages 1 1 and 12 to 
state that because interrupts are only generated during Vsync occurrences in steady state: 

CPU 54 advantageously has an entire Vsync time period (i.e., the time interval 
between two successive Vsync signals) to service those interrupt. In 
particular, when a Vsync signal arrives, CPU reads FIFO 48 to determine 
whether SD 26 has generated any tags. If one or more tags exist, CPU 
performs its assigned tasks and generates corresponding TDPs. However, 
CPU 54 has the entire period from the reading of the tags until the arrival of 
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the next Vsync signal to complete all of its tasks including the generation of 
the TDPs. Hence, CPU 54 may continue to finish its ongoing tasks 
uninterrupted, provided, however, that CPU 54 services the requested 
interrupt prior to the arrival of the next Vsync signal. Therefore, decoder 20 
benefits from very relaxed timing requirements. The relaxed timing 
requirements resulting from the availability of an entire Vsync period to CPU 
54 to read the tags and to generate corresponding TDPs is a significant 
advantage of DVD decoder 20 over the known DVD decoders which because 
they require their CPU control units (e.g. CPU) to immediately-but 
temporarily-abandon their ongoing tasks to service the interrupts in a very 
short time period, impose tight and rigid system timing requirements. 

Since interruptions of the control unit occur only at occurrences of the Vsync signal during 
steady-state operation and because the Vsync signal causes the video and audio decoders to 
decode the encoded video and audio data produced from the demultiplexed and depacketized 
incoming data stream, the demultiplexing and depacketizing of the data packs in the 
incoming data stream is done without interrupting the control unit. 

In the preferred embodiment described in the specification, the video messages which 
identify where the encoded video data is stored in the video input buffer and which also deal 
with the video timing information are provided by stream demultiplexer 26 to message queue 
106 where those video messages are available to CPU 54. The audio messages which 
identify where the encoded audio data is stored in the audio input buffer and which also deal 
with the audio timing information are, in the preferred embodiment, similarly provided by 
stream demultiplexer 26 to message queue 106 where those audio messages are available to 
CPU 54. This (temporary) storage site for the video and audio messages is described in 
pages 26 and 27 of the specification. 

On page 27, the specification describes how the use of message queue 106 enables 
stream demultiplexer 26 to avoid interrupting CPU 54. The specification particularly states 
in the second paragraph on page 27 that: 

Accordingly, SD 26 performs time/space multiplexing that allows 
CPU 54 to function in a batch mode rather than generating interrupts to CPU 
54 each time a significant piece of information is identified by SD 26. For 
example, message queue 106 as used by SD 26 represents an alternative 
approach to having SD 26 generate interrupts to CPU 54 each time SD 26 
identifies significant information (the interrupt approach). The interrupt 
approach is inefficient, because every time an interrupt is generated for CPU 
54, CPU 54 spends a few cycles processing the interrupt. Thus, SD 26 
advantageously uses message queue 106 to implement a hardware-based 
messaging system (hardware-based tagging mechanism). 
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The quoted material from page 27 of the specification shows how stream demultiplexer 26 
can perform its tasks, i.e., demultiplexing and depacketizing data packets of the incoming 
data stream, without interrupting CPU 54 and further supports the limitation of Claims 41 
and 67 that the demultiplexing and depacketizing of data packs be performed without 
interrupting the recited control unit. 

For the preceding reasons, the limitation of Claims 41 and 67 that the demultiplexing 
and depacketizing of data packs be done without interrupting the recited control unit is 
supported in the specification. 

The Examiner also seems to allege that the terms "video message" (or "video 
messages") and "audio message" (or "audio messages") in Claims 41 - 43, 51, 52, 57, 59, 
67 - 69, 74, and 75 are not supported by the specification. 

Claims 41 and 67, as amended, each specify that "video messages which identify 
where the encoded video data is stored in the video input buffer and which also deal with the 
video timing information" are generated for use by the control unit. Claim 48, not cited by 
the Examiner in the 35 USC 112 lack-of- support rejection, provides that "the video messages 
comprise tags which contain the timing information and the addresses of storage locations for 
the encoded video data in the video input buffer" where the expression "and the video input 
buffer" has been corrected here to "in the video input buffer". In the paragraph bridging 
pages 9 and 10, the specification provides that stream demultiplexer 26 "generates a tag 
which contains the DTS", i.e., the decode time stamp of a video PES data packet 206, "and 
the address of the stored data in FIFO 48". This tag implements each tag of Claim 48 and 
thus each video message of Claim 41 or 67. Accordingly, the video messages of 
Claims 41 - 43, 57, 59, and 67 - 69 are supported in the specification. 

Claims 51 and 74, as amended, each provide that "audio messages which deal with 
the audio timing information" are generated for use by the control unit. Claims 52 and 75 
each further provide that "the audio messages also indicate where the encoded audio data is 
stored in the audio input buffer". 

In the last paragraph on page 2, the specification states that the stream demultiplexer 
"generates a tag containing the decode time stamp, the presentation time stamp and the 
storage location of each data pack stored in the buffer". The tag recited on specification page 
2 contains either audio information or video information. Insofar as the tag contains audio 
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information, the tag implements each message of Claim 51 or 74. The specification later 
provides in the last paragraph on page 14 that stream demultiplexer 26 "generates a tag 
informing CPU 54 of the location of the stored audio frame in the buffer". The tag recited in 
the last paragraph on page 14 of the specification implements each audio message of 
Claim 52 or 75 insofar as the message indicates where the encoded audio data is stored in the 
audio input buffer. Consequently, the audio messages of Claims 51, 52, 74, and 75 are 
supported in the specification. 

The specification provides in the second paragraph on page 26 that "in one 
embodiment, SD 26 generates a message that audio or video data is stored in buffer 48 of 
Fig. 1 and ready for decoding even prior to storing all the audio or video data, respectively, in 
buffer 48". Aside from the recitation of stream-demultiplexer-generated messages in the 
just-quoted specification material, the specification itself does not appear to specifically 
define stream-demultiplexer-generated tags as "messages". However, originally filed device 
Claim 1 recited that the stream demultiplexer generates "messages about the stored data and 
their location in the data buffer" and that the control unit receives the so-generated messages. 
Originally filed method Claim 24 similarly recited "generating messages about the stored 
data bytes to a control unit". 

Originally filed device Claim 3 and method Claim 26 further particularized the 
"messages" respectively recited in Claims 1 and 24. Claim 3 recited that "the messages 
generated by the stream demultiplexer about the audio and the video components of a DVD 
or DVB data byte are recorded on tags containing information about the time stamp of the 
data and their storage location in the data buffer". Claim 26 recited that "the act of 
generating messages about the stored data bytes to a control unit comprises generating tags 
containing information about the time stamps of the data and their storage location in the data 
buffer". From the way that the "messages" are described in Claims 1, 3, 24, and 26, it is clear 
that the "messages" recited in Claims 41 - 43, 51, 52, 57, 59, 67 - 69, 74, and 75 correspond 
to the "messages" recited in Claims 1, 3, 24, and 26. Since the originally filed claims are part 
of the original disclosure of the present application, the term "message" or "messages" as 
used in Claims 41 - 43, 51, 52, 59, 67 - 69, 74, and 75 in describing information supplied by 
the stream demultiplexer and made available to the control unit is supported in the original 
disclosure. 
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To the extent that the previously mentioned "tags" should be expressly described as 
"messages", i.e., "audio messages" and "video messages", in the specification, this matter has 
been addressed by simply (a) inserting "video message" or "video messages" into the 
specification at appropriate points as an alternative expression for "tag" or "tags" containing 
the indicated video information and (b) inserting "audio message" or "audio messages" into 
the specification at appropriate points as an alternative expression for "tag" or "tags" 
containing the indicated audio information. The specification has thus been brought into 
conformity with the original claims so as to support the term "message" or "messages" 
employed in the present claims. 

For the preceding reasons, the 35 USC 112 lack-of-support rejection should be 
withdrawn. 

Claims 41-82 have been rejected under 35 USC 1 12 as indefinite for failing to 
particularly point out and distinctly claim the invention. The Examiner alleges that the term 
"video messages" in Claims 41 and 67 and the term "audio messages" in Claims 51, 52, 74, 
and 75 are indefinite. This rejection is respectfully traversed. 

The specification has, as indicated above, been brought into conformity with the 
original claims by incorporating the term "message" or "messages" from the original claims 
into the specification at appropriate points as an alternative expression for the term "tag" or 
"tags" in the same sense that "message" or "messages" was employed in the original claims 1 . 



On page 3 of the Office Action, the Examiner alleges that "The term 'video messages' in claims 41 and 67 
are used by the claim to mean "tags which contain the timing and addresses of storage location for encoded 
video data in the video buffer' while the accepted meaning is Video picture.'". Referring to the language 
employed in Claim 48, the "tags which contain the timing information and the addresses of storage locations for 
the encoded video data in the video input buffer" are not data that contains the substantive details of the picture 
being presented but instead are data that deals with where the substantive picture details are located and when 
the substantive picture data is to be decoded and presented . If the Examiner is attempting to say that "video 
picture" is the accepted term for "tags which contain the timing information and the addresses of storage 
locations for the encoded video data in the video input buffer" and if this 35 USC 112 indefiniteness rejection is 
continued, Applicants' Attorney requests the Examiner to provide Applicants' Attorney with material that 
supports the Examiner's allegation. 

The Examiner further alleges on page 3 of the Office Action that "The term 'audio messages' in claims 
51-52 an [sic, and] 74-75 are used by the claim to meet 'audio timing information and the location of encoded 
audio data in the audio buffer', while the accepted meaning is 'audio data'". The "audio timing information and 
the location of the encoded audio data in the audio buffer" is not data that contains the substantive details of the 
sound being presented but instead is data that deals with where the substantive sound data is located and when 
the substantive sound data is to be decoded and presented . If the Examiner is attempting to say that "audio data 
is the accepted term for "audio timing information and the location of encoded audio data in the audio buffer" 
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The claims employ the terms "video" and "audio" as modifiers for "message" or "messages" 
solely to distinguish the "messages" dealing with video information from the "messages" 
dealing with audio information. Consequently, the terms "video" and "audio" as modifiers 
for "message" or "messages" are appropriate and reasonable. Since the terms "video 
messages" and "audio messages" are now appropriately used and thus defined in the 
specification, the 35 USC 1 12 indefiniteness rejection should be withdrawn. 

Claims 41, 48 - 52, 55 - 58, 62 - 67, 74, 75, 78, 81, and 82 have been rejected under 
35 USC 103(a) as obvious based on Okada et al. ("Okada"), U.S. Patent No. 5,668,601, in 
view of Maturi et al. ("Maturi"), U.S. Patent No. 5,559,999. This rejection is respectfully 
traversed. 

Okada discloses an audio/video decoding system having parser 4, audio decoder 2, 
and video decoder 3. Parser 4, including internal demultiplexer 5, separates (demultiplexes 
and depacketizes) an incoming audio/video data stream into an audio data stream, an audio 
presentation time stamp, a video data stream, a video presentation time stamp, and a system 
clock reference. The audio presentation time stamp and the audio data stream are 
respectively sequentially stored in first-in- first-out ("FIFO") register 1 1 and FIFO bit buffer 
12, both of which are components of audio decoder 2. The video presentation time stamp 
and the video data stream are respectively sequentially stored in FIFO register 21 and FIFO 
bit buffer 22, both of which are components of video decoder 3. The system clock reference 
goes to controllers 14 and 24 of respective decoders 2 and 3. 

Bit buffers 12 and 22 automatically sequentially provide the audio and video data 
streams respectively to decoder core circuits 13 and 23 of decoders 2 and 3 for decoding and 
presentation in synchronism at times determined respectively by controllers 14 and 24. 
Audio controller 14 determines when audio decode core circuit 13 decodes the current audio 
data of the audio data stream as a function of the system clock reference, the audio 
presentation time stamp, and the various transmission-delay/processing times in audio 
decoder 2. Video controller 24 similarly determines when video decode core circuit 23 
decodes the current video data of the video data stream as a function of the system clock 
reference, the video presentation time stamp, and the various transmission-delay/processing 
times in video decoder 3. The decoding and presentation of the video data is synchronized to 

and if this rejection is continued, Applicants' Attorney requests the Examiner to provide Applicants' Attorney 
with material supporting the Examiner's further allegation. 
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the decoding and presentation of the audio data by way of the system clock reference 
supplied to controllers 14 and 24. 

Maturi discloses an interrupt-based system for decoding an incoming audio/video 
data stream. Pre-parser 22 parses (demultiplexes and depacketizes) the audio/video data 
stream, stores the audio and video headers respectively in audio and video buffers 20c and 
20a, and stores the audio and video data respectively in audio and video channel buffers 20d 
and 20b. In storing the audio and video headers in header buffers 20c and 20a, pre-parser 22 
interrupts host microcontroller 18 and provides the audio and video headers with respective 
tags that identify the starting channel-buffer addresses of the audio and video data. In 
response to the interrupt, microcontroller 18 extracts the presentation time stamps from pre- 
parser 22 and stores the presentation time stamps in memory 18a. Audio and video decoders 
28 and 26 later respectively decode the audio and video data under the synchronism control 
of microcontroller 18. 

Independent Claims 41 and 67, as amended, respectively recite: 

41. A decoder system comprising; 

a control unit; 

a data buffer comprising a video input buffer and an audio input 

buffer; 

a stream demultiplexer for receiving an incoming data stream 
comprising data packets each comprising at least one of (i) encoded video data 
and a video header that contains video timing information for the encoded 
video data and (ii) encoded audio data and an audio header that contains audio 
timing information for the encoded audio data, the stream demultiplexer 
operating 

(a) to demultiplex and depacketize the data packets without 
interrupting the control unit, 

(b) to send the encoded video data to the video input buffer for storage 
there without the video timing information, 

(c) to provide, for use by the control unit, video messages which 
identify where the encoded video data is stored in the video input buffer and 
which also deal with the video timing information, and 

(d) to send the encoded audio data to the audio input buffer for storage 

there; 
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a video decoder that decodes the encoded video data to produce 
decoded video data utilizing video instructions provided from the control unit 
as to where the encoded video data is stored in the video input buffer; and 

an audio decoder that decodes the encoded audio data to produce 
decoded audio data. 

67. A method comprising: 

receiving an incoming data stream comprising data packets each 
comprising at least one of (i) encoded video data and a video header that 
contains video timing information for the encoded video data and (ii) encoded 
audio data and an audio header that contains audio timing information for the 
encoded audio data; 

demultiplexing and depacketizing the data packs without interrupting a 
control unit; 

storing the encoded video data in a video input buffer without the 
video timing information; 

providing, for use by the control unit, video messages which identify 
where the encoded video data is stored in the video input buffer and which 
also deal with the video timing information; 

decoding the encoded video data to produce decoded video data using 
video instructions provided from the control unit as to where the encoded 
video data is stored in the video input buffer; 

storing the encoded audio data in an audio input buffer; and 

decoding the encoded audio data to produce decoded audio data. 

Importantly, Claims 41 and 67 each require that there be generated, for use by the 
control unit, video messages which identify where the encoded video data is stored in the 
video input buffer. In Claim 41, the stream demultiplexer generates the video messages. 
Because video bit buffer 22 in Okada is a FIFO, Okada does not generate video messages 
akin to the video messages of Claims 41 and 67. This is acknowledged in the Office Action 
by the statement on page 5 that "Okada fails to disclose a step of providing [video messages 
which] identify where the encoded video data is stored in the video input buffer and audio 
messages which identify the location of encoded audio data in the audio buffer and PTS and 
system clock and timer for maintaining local time". 

The Examiner attempts to combine Maturi and Okada in an effort to make up for the 
fact that Okada does not generate, for use by a control unit such as video controller 24, video 
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messages which identify where the encoded video data is stored in bit buffer 22. After 
stating later on page 5 of the Office Action that "Maturi discloses a method and apparatus for 
transferring the tags to the control unit which contain PTS and location of address buffer for 
video and audio data (Fig 4); system clock and timer for maintaining local current time (Fig 
3, Ref 40) and message queue (Fig 3, Ref 18a)", the Examiner alleges that "Therefore, it 
would have been obvious to one of ordinary skill in the art at the time of the invention was 
made to apply a method of providing a control unit with tags that includes timing and 
location of the encoded audio and video data as disclosed by Maturi into Okada's system" 
and that "The motivation would have been to synchronize the video and audio data". 

The Examiner's rationale for combining Okada and Maturi is illogical. Synchronism 
of Okada's audio and video data, i.e., synchronism of the times at which the audio and video 
data are decoded by decode core circuits 13 and 23 for presentation is already achieved by 
controllers 14 and 24 in response to the system clock reference based on the audio and video 
presentation time stamps. There is no need for using an additional technique, such as that 
disclosed in Maturi, for synchronizing Okada's audio and video data. Consequently, there is 
no motivation for applying Maturi to Okada in the manner, and for the reasons, proposed by 
the Examiner. 

Modifying Okada's decoding system to include both Okada's current technique for 
synchronizing the decoding and presentation of the audio and video data and Maturi's 
technique for synchronizing the decoding and presentation of the audio and video data would 
simply increase the amount of circuitry, and associated cost, without providing a significant 
(if any) improvement in performance. In fact, compatibility problems could arise from the 
presence of two systems for synchronizing the decoding and presentation of the audio/video 
data, e.g., when the decoding/presentation times determined by one of the synchronization 
systems differs from the decoding/presentation times determined by the other 
synchronization system. A person skilled in the art would not modify Okada's decoding 
system to include both techniques for synchronizing the decoding and presentation of the 
audio and video data. 

As pointed out above, host microcontroller 18 in Maturi is interrupted during the 
demultiplexing and depacketizing of the incoming audio/video data stream to retrieve the 
video timing information, namely the video presentation time stamps, from pre-parser 22. 
Claims 41 and 67 each require that the demultiplexing and depacketizing of the data packs be 
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done wi thout interrupting the control unit. Even if there was some motivation for modifying 
Okada's decoder to include Maturi's technique for synchronizing the decoding and 
presentation of the audio and video data as a replacement for Okada's current technique for 
synchronizing the decoding and presentation of the audio and video data, the utilization of 
Maturi's synchronization technique would require that the control unit in the so-modified 
decoding system be interrupted during the demultiplexing and depacketizing of the incoming 
audio/video data stream to obtain the video timing information present in the incoming data 
stream. Accordingly, the so-modified decoding system would not meet the limitation of 
Claim 41 or 67 that the demultiplexing and depacketizing of the data packs be done without 
interrupting the control unit. 

In short, there is no motivation for combining Okada and Maturi in the proposed 
manner. Modifying Okada's decoding system to include system to include both Okada's 
current technique for synchronizing the decoding and presentation of the audio and video 
data and Maturi's technique for synchronizing the decoding and presentation of the audio and 
video data leads to a non-useful result. Replacing Okada's current system for synchronizing 
the decoding and the presentation of the audio and video data with Matures system for 
synchronizing the decoding and presentation of the audio and video data would, even if some 
motivation could be found to do so, not result in a system that meets all the limitations of 
Claim 41 or 67. Hence, Claims 41 and 67 are patentable over Okada and Maturi. 

Claims 48 - 52, 55 - 58, and 62 - 66 all depend from (directly or indirectly) from 
Claim 41. Claims 74, 75, 78, 81, and 82 all depend (directly or indirectly) from Claim 67. 
Hence, Claims 48 - 52, 55 - 58, 62 - 66, 74, 75, 78, 81, and 82 are patentable over Okada and 
Maturi for the same reasons as Claims 41 and 67. 

Claims 53, 54, 76, and 77 have been rejected under 35 USC 103(a) as obvious based 
on Okada and Maturi in view of Nuber et al. ("Nuber"), U.S. Patent No. 5,703,877. Claim 61 
has been rejected under 35 USC 103(a) as obvious based on Okada and Maturi in view of 
Terashima et al. ("Terashima"), U.S. Patent No. 6,163,647. These rejections are respectfully 
traversed. 

Claims 53, 54, and 61 each depend (directly or indirectly) from Claim 41 rejected as 
obvious based on Okada and Maturi. Claims 76 and 77 each depend (directly or indirectly) 
from Claim 67 likewise rejected as obvious based on Okada and Maturi. For the reasons 
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presented above, Claims 41 and 67 are not obvious based on Okada and Maturi. Nothing in 
Nuber or/and Terashima would justify combining Okada and Maturi so as to make Claim 41 
or 67 obvious. Claims 53, 54, 61, 76, and 77 are thus variously patentable over Okada, 
Maturi, and Nuber or Terashima for the same reasons that Claims 41 and 67 are patentable 
over Okada and Maturi. 

None of Claims 42 - 47, 59, 60, 68 - 73, 79, and 80 has been rejected on prior art 
grounds. Inasmuch as the 35 USC 1 12 rejections have been shown to be inappropriate, 
Claims 42 - 47, 59, 60, 68 - 73, 79, and 80 are allowable. 

To summarize, the 35 USC 112 lack-of-support and indefiniteness rejection should be 
withdrawn. Claims 41, 48 - 58, 61 - 67, 74 - 78, 81, and 82 have been shown to be 
patentable over the applied art. Accordingly, Claims 41-82 should be allowed so that the 
application may advance to issue. 

Please telephone Attorney for Applicant(s) at 650-964-9767 if there are any 
questions. 
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